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(54) Dynamic adjustment of logical processor configuration 



(57) The configuration of the logical processors of a 
logical partition is managed dynamically. A logical par- 
tition is initially configured with one or more logical proc- 



essors. Thereafter, the configuration can be dynamically 
adjusted. This dynamic adjustment may be in response 
to workload of the logical partition. 
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Description 

[0001] This invention relates, in general, to managing 
logical processors in a computing environment, and par- 
ticularly to one including one or more logical partitions. 
[0002] Logical partitioning allows the establishment of 
a plurality of system images within a single physical ma- 
chine or central processor complex (CPC). Each system 
image is capable of operating as if it was a separate 
computer system. That is, each logical partition can be 
independently reset, initially loaded with an operating 
system that may be different for each logical partition, 
and operated with different software programs using dif- 
ferent input/output (I/O) devices. 
[0003] Examples of logically partitioned computing 
systems are described in, for instance, U.S. 4,564,903, 
issued on January 14, 1986; U.S. 4,843,541, issued on 
June 27, 1989; and U.S. 5,564,040, issued on October 
08, 1996. 

[0004] Commercial embodiments of logically parti- 
tioned systems include, for example, IBM S/390® proc- 
essors with the Processor Resource/Systems Manag- 
er™ (PR/SM™) feature, which is described, for in- 
stance, in the IBM publication Processor Resource/Sys- 
tems Manager Planning Guide , GA22-7236-04, March 
1999. 

[0005] One important aspect of a logically partitioned 
system is the management of workload running within 
the partitions of that system. In S/390 systems, for ex- 
ample, workload managers are used to manage the 
workload within and among the partitions. The workload 
managers attempt to balance the workload of the parti- 
tions by moving work to the physical resources of the 
system. In order to move the work, however, it is impor- 
tant to ensure that the data needed by the relocated 
work is at the moved location. This need often restricts 
the movement of work. Thus, it is desirable to further 
improve workload management in computer systems. 

Summary of the Invention 

[0006] Accordingly, the invention provides a method 
of managing logical processors of a computing environ- 
ment including one or more logical partitions, said meth- 
od comprising the steps of: 

configuring a logical partition of said computing en- 
vironment with one or more logical processors; and 
dynamically adjusting the configuration. 

[0007] In a preferred embodiment, said dynamically 
adjusting is in response to the workload of said logical 
partition, and may increase or decrease the number of 
logical processors allocated to said logical partition. A 
determination that said configuration is to be adjusted 
is preferably performed at a plurality of times, typically 
at regularly spaced intervals. The determination is made 
using a predefined equation; the result of this can be 



compared with one or more thresholds to determine 
whether the adjustment is to be made. 
[0008] In the preferred embodiment, said predefined 
equation comprises: L=floor[max(W,U) *P+1.5], 
5 wherein: L=number of logical processors configured to 
said logical partition; W=percentage of central proces- 
sor capacity assigned to said logical partition; U=per- 
centage of central processor capacity currently being 
utilized by said logical partition; and P=numberof phys- 
io ical processors that can be allocated on the central proc- 
essor associated with said logical partition. This is sub- 
ject to a maximum of L=P (ie the number of logical proc- 
essor cannot exceed the number of physical proces- 
sors). 

15 [0009] The invention further provides a computer pro- 
gram for implementing a method such as described 
above. Such a program will typically be encoded on a 
computer usable media, which may be included as a 
part of a computer system or sold separately. In other 

20 words, such a computer usable media or program stor- 
age device contains program instructions executable by 
the machine in order to perform the methods described 
above. 

[0010] The invention further provides a system for 
25 managing logical processors in a computing environ- 
ment including one or more logical partitions, said sys- 
tem comprising: 

means for configuring a logical partition of said com- 
30 puting environment with one or more logical proc- 
essors; and 

means for dynamically adjusting the configuration. 

[0011] The dynamic adjustment of the configuration 
35 of logical processors of logical partitions in a computing 
environment allows the number of logical processors 
configured to a logical partition to remain close to the 
number of physical CPUs desired to provide the CPC 
capacity assigned to (or used by) a logical partition. 
40 Thus, the number of logical processors to manage is 
minimized. 

[0012] Various preferred embodiments of the inven- 
tion will now be described in detail by way of example 
only with reference to the following drawings: 

45 

FIG. 1a depicts one example of a computing envi- 
ronment; 

FIG. 1 b depicts a further embodiment of a comput- 
ing environment; 
50 FIG. 2 depicts additional components of a comput- 
ing environment; 

FIG. 3 depicts one example of logical partition 
groups; 

FIGs. 4a-4b depict one example of the logic asso- 
55 ciated with a partition joining a group; 

FIG. 5 depicts one embodiment of the logic associ- 
ated with removing a partition from a group; 
FIG. 6 depicts one embodiment of the logic associ- 
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ated with determining if a partition's weight can be 
increased to help a receiver service class of the par- 
tition; and 

FIG. 7 depicts one embodiment of the logic associ- 
ated with dynamically adjusting the configuration of 
logical processors. 

[0013] Workload management capabilities are pro- 
vided that enable the dynamic adjustment of the alloca- 
tion of resources of a computing environment to balance 
the workload of that environment. In one example, the 
computing environment includes a plurality of logical 
partitions and the workload is managed across two or 
more of the partitions. 

[0014] One embodiment of a computing environment 
using workload management capabilities is described 
with reference to FIG. 1a. A computing environment 100 
is based, for instance, on the Enterprise Systems Archi- 
tecture (ESA)/390 offered by International Business Ma- 
chines Corporation, Armonk, New York. ESA/390 is de- 
scribed in an IBM publication entitled "Enterprise Sys- 
tems Architecture/390 Principles Of Operation," IBM 
Publication No. SA22-7201-04, June 1997. One exam- 
ple of a computing environment based on ESA/390 is 
the 9672 Parallel Enterprise Server offered by Interna- 
tional Business Machines Corporation. 
[0015] Computing environment 100 includes, for ex- 
ample, a central processor complex (CPC) 102 having 
one or more central processors 106 (e.g., CP1-CP4), 
one or more partitions 108 (e.g., logical partitions 
(LP1-LP4)), and at least one logical partition manager 
110, each of which is described below. 
[0016] Central processors 106 are physical processor 
resources that are allocated to the logical partitions. In 
particular, each logical partition 108 has one or more 
logical processors (not separately shown for clarity), 
each of which represents all or a share of a physical 
processor 106 allocated to the partition. The logical 
processors of a particular partition 108 may be either 
dedicated to the partition (so that the underlying proc- 
essor resource 106 is reserved for that partition) or 
shared with another partition (so that the underlying 
processor resource is potentially available to another 
partition). 

[0017] In the particular example shown, each of logi- 
cal partitions LP1-LP4 functions as a separate system 
having a resident operating system 112 (which may dif- 
fer for each logical partition) and one or more applica- 
tions 114. In one embodiment, operating system 112 is 
the OS/390™ or MVS/ESA™ operating system offered 
by International Business Machines Corporation. 
[0018] Additionally, each operating system (or a sub- 
set thereof) includes a workload manager 116 for man- 
aging the workload within a partition and among parti- 
tions. One example of a workload manager is WLM of- 
fered by International Business Machines Corporation. 
WLM is described in, for instance, U.S. 5,473,773, is- 
sued December 5, 1995; and U.S. 5,675,739, issued 



October 7, 1997. 

[0019] Logical partitions 108 are managed by logical 
partition manager 110 implemented by microcode run- 
ning on processors 106. Logical partitions 108 
5 (LP1-LP4) and logical partition manager 110 each com- 
prise one or more programs residing in respective por- 
tions of central storage associated with the central proc- 
essors. One example of logical partition manager 110 is 
PR/SM. 

10 [0020] In a further embodiment of a computing envi- 
ronment, two or more central processor complexes are 
coupled to one another to form a sysplex, as depicted 
in FIG. 1b. As one example, a central processor com- 
plex (CPC) 102 is coupled to one or more other CPCs 

15 120 via, for instance, a coupling facility 122. 

[0021] In the example shown, CPC 120 includes a 
plurality of logical partitions 124 (e.g., LP1-LP3), which 
are managed by a logical partition manager 126. One 
or more of the logical partitions includes an operating 

20 system, which may have a workload manager and one 
or more application programs (not shown in this exam- 
ple for clarity). Additionally, CPC 1 20 includes a plurality 
of central processors 1 28 (e.g., CP1- CP3), the resourc- 
es of which are allocated among the plurality of logical 

25 partitions. In particular, the resources are allocated 
among one or more logical processors 130 of each par- 
tition. (In other embodiments, each CPC may have one 
or more logical partitions and one or more central proc- 
essors.) 

30 [0022] Coupling facility 1 22 (a.k.a., a structured exter- 
nal storage (SES) processor) contains storage accessi- 
ble by the central processor complexes and performs 
operations requested by programs in the CPCs. The 
coupling facility is used for the sharing of state informa- 

35 tion used in making shared resource redistribution de- 
cisions. (In one embodiment, each central processor 
complex is coupled to a plurality of coupling facilities.) 
Aspects of the operation of a coupling facility are de- 
scribed in detail in such references as Elko et al., U.S. 

40 5,31 7,739, issued May 31 , 1 994; U.S. 5,561 ,809, issued 
October 1, 1996; U.S. 5,706,432, issued January 6, 
1 998; and the patents and applications referred to there- 
in. 

[0023] In one embodiment, one or more of the central 
45 processors are coupled to at least one channel subsys- 
tem, which is used in communicating with I/O devices. 
For example, a central processor 200 (FIG. 2) is coupled 
to main storage 202 and at least one channel subsystem 
204. Channel subsystem 204 is further coupled to one 
so or more control units 206. The control units are then cou- 
pled to one or more I/O devices 208. 
[0024] The channel subsystem directs the flow of in- 
formation between the input/output devices and main 
storage. It relieves the central processing units of the 
55 task of communicating directly with the input/output de- 
vices and permits data processing to proceed concur- 
rently with input/output processing. The channel sub- 
system uses one or more channel paths 214 as com- 
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munication links in managing the flow of information to 
or from input/output devices 208. 
[0025] Each channel path 214 includes, for instance, 
a channel 210 of channel subsystem 204, a control unit 
206 and a link 21 2 between the channel and control unit. 5 
In other embodiments, a channel path may have multi- 
ple channels, control units, and/or links. Further, in an- 
other example, it is also possible to have one or more 
dynamic switches as part of the channel path. A dynam- 
ic switch is coupled to a channel and a control unit and 10 
provides the capability of physically interconnecting any 
two links that are attached to the switch. Further details 
regarding channel subsystems are described in U.S. 
5,526,484, issued on June 11, 1996. 
[0026] In a preferred embodiment of the present in- 15 
vention, various physical resources are dynamically re- 
distributed across the logical partitions of a computing 
environment under direction of one or more workload 
managers. This dynamic redistribution is transparent to 
the application subsystems. As examples, the physical 20 
resources to be redistributed include CPU resources, 
logical processor resources, I/O resources, coproces- 
sors, channel resources, network adapters, and mem- 
ory resources. As one example, a coprocessor is a mi- 
croprocessor (other than a CPU) within a CPC that 25 
serves a particular function. Examples of coprocessors 
include, for instance, channel subsystems, network 
adapter cards and cryptographic coprocessors. The 
above physical resources are only offered as examples; 
other shareable resources may also be redistributed. 30 
[0027] In order to facilitate the dynamic redistribution 
of resources, in one embodiment, logical partitions are 
grouped together in order to share the resources among 
the partitions of the group. Each group can vary in size 
from 1 partition to n partitions. (In one example, one or 35 
more of the groups include one or more partitions, but 
less than all of the partitions of the computing environ- 
ment.) In particular, each group includes, for instance, 
one or more operating system images running in inde- 
pendent domains of a machine, which are managed by 40 
a common workload manager function to distribute 
workloads and resources. In one example, these do- 
mains are logical partitions running in logically parti- 
tioned mode and the operating systems are OS/390 run- 
ning in the logical partitions. The logical partitions of a ^ 
group may be a subset of the partitions of a system (e. 
g., a CPC) or a sysplex, an entire system or sysplex, or 
may be partitions of different sysplexes (on, for exam- 
ple, a single CPC) or systems. 

[0028] One embodiment of two logical partition so 
groups (or clusters) of a central processor complex is 
depicted in FIG. 3. As shown, there is a Logical Partition 
Group A 300 and a Logical Partition Group B 302, each 
of which includes one or more logical partitions. The 
grouping of logical partitions enables resource sharing 55 
among the partitions of a group through resource allo- 
cation (e.g., priority based resource allocation). 
[0029] As examples, the resources to be shared in- 



clude CPU resources, I/O resources, and memory, as 
well as co- processors or any other shareable resources 
the machine might provide. A particular logical partition 
group may or may not have access to all of the resourc- 
es of a particular machine. In fact, multiple logical par- 
tition groups could be defined to operate concurrently 
on a single machine. In order to manage each logical 
partition group effectively, the resources that make up a 
particular logical partition group are effectively scoped 
to that group. 

[0030] The scoping includes identifying which re- 
sources are allocatable to each group. In particular, the 
scope defines which resources are restricted to the 
group and can be managed for the group. The logical 
partitions that make up a logical partition group can be 
thought of as a container of the resources. These con- 
tainers exist within the bounds of a total set of resources 
available to the logical partitions. In one example, this 
is the total set of resources available on a particular 
CPC. 

[0031] The logical partitions that make up a particular 
logical partition group (e.g., Logical Partition Group A) 
are assigned a particular portion of the total shareable 
resource. For example, assume that the shareable re- 
source is a CPU resource. With shared CPU resources, 
the logical partitions that are included in Logical Partition 
Group A are assigned a particular portion of the total 
central processor complex CPU resource. These re- 
sources are being shared by the logical partitions within 
a particular group, as well as, potentially, with logical 
partitions in other logical partition groups and logical 
partitions not included in any logical partition groups. 
Thus, a workload manager that is trying to make deci- 
sions about moving resources within a group (from, for 
instance, one partition in the logical partition group to 
another partition in the group) is to have an understand- 
ing of the resources that comprise the group, as well as 
an understanding of what the larger container (e.g., the 
CPC) contains. Measurement feedback (e.g., state in- 
formation stored in the coupling facility) used to make 
decisions about managing workload resources should 
be sufficient to understand the customer defined con- 
tainers as above. 

[0032] Once this understanding is established, work- 
load manager directed changes to the resource alloca- 
tions in the logical partitions of a given group are typi- 
cally done in such a way that keeps the container size 
(i.e., the resources allocated to the logical partition 
group) constant. For instance, assume that the resource 
to be managed is the CPU resource, and further assume 
that each logical partition is assigned a CPU processing 
weight that indicates priority. In order to manage the 
CPU relative weights, the sum of the relative weights for 
the logical partitions in a given group are to remain con- 
stant before and after the directed change, via, for in- 
stance, workload manager. This maintains the customer 
specified allocation of the resources to the groups and 
other logical partitions present on the machine. 
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[0033] Notwithstanding the above, in some cases it 
may be desirable and possible for the group of partitions 
to utilize resources greater than the defined container, 
when those resources are not being used by their des- 
ignated owners. However, as soon as contention for the 
resources occurs, the resources are managed by the 
logical partition (LPAR) manager according to the de- 
fined container sizes (e.g., processing weights in this 
example). There may, however, be other cases when 
the group should not be allowed to expand beyond its 
container This is also possible with scoping. Other re- 
sources may need to be fully scoped to a single group 
in order to get an accurate picture of usage of the re- 
sources. Limiting in this fashion prevents logical parti- 
tions outside of a given group from accessing that re- 
source. 

[0034] In addition to the above, consideration is also 
given to the effect of external changes on the availability 
of resources within a logical partition group. For exam- 
ple, a user may change the allocation of resources via 
some external means (not under workload manager di- 
rection). This might be done because of a change in ac- 
tual workloads that are on a machine or a shift in busi- 
ness priorities between groups and/or other logical par- 
titions. When these changes are made, these changes 
are to be understood by the workload manager and the 
effects of these changes are to be distributed rationally. 
Changes might occur when a logical partition is added 
to or removed from a group; when some other logical 
partition outside the group is added or removed; or sim- 
ply, when a processing weight change is effected via ex- 
ternal means. When these external changes are per- 
formed, the size of the container can change and work- 
load manager is now the manager of that newly sized 
container. 

[0035] When resources attributed to a particular logi- 
cal partition of a group are changed externally, a redis- 
tribution of resources within a group may be needed. 
For instance, when a logical partition is removed from a 
group, the processing weight associated with that logi- 
cal partition is removed from the group. If the current 
workload manager assigned weight for the logical par- 
tition is greater than the logical partition's weight that is 
being removed (i.e., the processing weight associated 
with the logical partition initially), the difference in weight 
is added to other logical partitions in the group. This is 
done, for instance, in proportion to the existing distribu- 
tion of weights in the other logical partitions in the group. 
If the current workload manager assigned weight for the 
logical partition is less than the logical partition's initial 
weight, the difference in weight is subtracted from the 
other logical partitions in the group. Again, this is done 
in proportion to the other logical partition weight assign- 
ments, as one example. 

[0036] As described above, a group is scoped in order 
to obtain a handle on the resources that are assigned 
to a group and the resources that are allowed to change, 
so that the workload manager can make proper deci- 



sions of what to do next. The scoping identifies the 
groups and provides information back to the program 
that the program can understand. When a group is mod- 
ified, the resources are dynamically adjusted to satisfy 

5 the modification. 

[0037] In one embodiment, there can be separate 
groups (clusters) for each resource. For example, Log- 
ical Partition Group A may be for CPU resources, while 
Logical Partition Group B may be for I/O resources. 

10 However, in other embodiments, it is also possible that 
one logical partition group is for a subset or all of the 
resources. 

[0038] In order to establish LPAR group scope, in one 
example, the logical partitions identify themselves to 

15 one or more groups of partitions. One embodiment of 
the logic associated with joining a group is described 
with reference to FIGs. 4a-4b. For example, to join a log- 
ical partition group, the operating system (e.g., OS/390) 
running in a logical partition indicates to the LPAR man- 

20 ager which LPAR group the logical partition is to be a 
part thereof, STEP 400. As one example, an instruction 
is used to pass the LPAR group name to the LPAR man- 
ager. The operating system specifies a name for each 
type of resource that is to be managed within LPAR 

25 groups. Thus, if there are other resources, INQUIRY 
402, then other names are specified. For example, a 
group name is given for CPU resources and another 
name is given for I/O resources. The same LPAR group 
name can be specified for each resource type, if desired. 

30 [0039] This declaration by OS/390 either establishes 
a new LPAR group on the machine (if the logical partition 
is the first logical partition to use that name) or causes 
this logical partition to join an existing LPAR group of the 
same name for that resource type. For example, once 

35 the group name is specified, STEP 404 (FIG. 4b), a de- 
termination is made as to whether it is a new name, IN- 
QUIRY 406. If so, a new group is created, STEP 408. 
[0040] Otherwise, an existing group is joined, STEP 
410. Thereafter, the resources are scoped to the group, 

40 STEP 412. 

[0041] In particular, the resources of the group type 
that are bound to the LPAR group are now made avail- 
able for that logical partition to utilize, if and when WLM 
running in the LPAR group determines it should. The re- 

45 sources of a particular type for an LPAR group that need 
scoping include at least two varieties: additive resources 
and fixed resources. 

[0042] Additive Resources: In some cases, joining an 
LPAR group inherently adds resources to the LPAR 

so group that the logical partition just joined. An example 
of this is CPU processing weight, which is, for example, 
assigned by the customer to a logical partition at a hard- 
ware console. The current (in use) processing weight of 
the logical partition is initialized from this customer as- 

55 signed weight, when the logical partition is activated. 
When the logical partition joins an LPAR group for CPU 
resources, the customer assigned processing weight for 
that logical partition becomes part of the total processing 
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weight available for use within the LPAR group, and 
thus, can be reassigned within the LPAR group by WLM. 
The logical partition that just joined the LPAR group now 
has the potential to use the larger set of LPAR group 
resources, to which a contribution was just made. 5 
[0043] Fixed Resources: In some cases, a set of re- 
sources is predefined as belonging to a particular LPAR 
group. An example of this is managed (floating) channel 
paths. A managed channel path is a channel path whose 
resources can be reassigned to help achieve workload *o 
goals. The set of managed channel paths for use by a 
particular LPAR group is initially defined via an I/O con- 
figuration definition process that associates channel 
paths (CHPIDs) with an LPAR group. When a logical 
partition joins this LPAR group, it is now allowed access is 
to this set of channel paths. The logical partition itself 
did not contribute anything to this resource pool. (This 
pool of resources can still be changed dynamically, but 
the point is that the resources do not come and go as 
logical partitions join and leave an LPAR group.) 20 
[0044] LPAR scope can also be enforced differently 
for resources depending on the type of resource. 
[0045] Additive Resources: The operating system in 
an LPAR group is to be able to query the complete set 
of resources of this type for the LPAR group. As an ex- 25 
ample, for CPU processing weights, this is accom- 
plished via an instruction. The operating system learns 
the total set of this resource type within the LPAR group, 
the allocation of the resources to the logical partitions in 
the group, and the complete size of the resource pool 30 
available on the current machine. All these components 
are used to understand how much of the total physical 
resource is to be allocated to a logical partition. The op- 
erating system then updates the allocations to the logi- 
cal partitions in the LPAR group to reassign resources 35 
within the group. The operating system is not allowed, 
in one example, to change the total amount of resource 
allocated to the LPAR group. The LPAR manager en- 
forces this by making sure that all parts of the LPAR 
group are accounted for in an update and no logical par- <o 
titions outside the LPAR group have their resources af- 
fected. 

[0046] Fixed Resources: The operating system in an 
LPAR group queries the set of resources that is associ- 
ated with its LPAR group for this type of resource. For *5 
example, with managed channel paths, a list of man- 
aged channel paths that are defined for a particular 
LPAR group can be retrieved from the LPAR manager 
via an instruction. The LPAR manager also screens 
these resources to make sure they are only utilized by so 
the proper LPAR group. For managed channels, this 
means only allowing a managed channel path to be con- 
figured online to a logical partition that has declared an 
LPAR group name that matches that defined for the 
managed channel path. 55 
[0047] When a logical partition that is part of an LPAR 
group is system reset, re-IPLed, or deactivated, any af- 
filiation that logical partition had with one or more LPAR 



groups is removed. One embodiment of the logic asso- 
ciated with removing a logical partition from a group is 
described with reference to FIG. 5. As part of the reset, 
the logical partition manager removes a declared LPAR 
partition group name(s) from the logical partition, STEP 
500. Then, one or more other actions are performed to 
complete the LPAR group resource deallocation for the 
logical partition, depending on the resource, INQUIRY 
502. 

[0048] If the resource is an additive resource, then the 
following occurs: resources such as this, that were add- 
ed into an LPAR group when a logical partition joined 
the LPAR group, are removed from the LPAR group, 
STEP 504. This may involve an adjustment in the cur- 
rent allocation of this type of resource to the remaining 
members of the LPAR group. For instance, in the case 
of processing weights, the initial processing weight for 
the logical partition leaving the group is now removed 
from the scope of the LPAR group. If WLM had changed 
the current processing weight for the logical partition, 
adjustments need to be made. If the logical partition's 
current processing weight is greater than its initial 
processing weight, the difference between the two is re- 
distributed to the remaining LPAR group members in 
proportion to their current processing weights. If the log- 
ical partition's current processing weight is less than its 
initial processing weight, the difference between the two 
is removed from the remaining LPAR group members in 
proportion to their current processing weights. The re- 
sult of these adjustments re-establishes the processing 
weight container for the resulting LPAR group. 
[0049] On the other hand, if the resource is a fixed 
resource, then the following occurs: resources such as 
these are simply removed from the configuration of the 
logical partition being reset, STEP 506. For instance, for 
managed channel paths, the channel paths are decon- 
figured from the logical partition being reset. This once 
again re-establishes that only members of the LPAR 
group have access to the LPAR group resource. 
[0050] It should also be noted that some resources 
managed by WLM in an LPAR group environment may 
not have a need for group scoping. One example of such 
a resource is the number of logical central processors 
(CP) online for a logical partition. The effective behavior 
of a particular logical partition in an LPAR group can be 
significantly influenced by the number of logical CPs that 
are online to the logical partition. The number of logical 
CPs that a logical partition can have defined and/or on- 
line is a characteristic of a logical partition whether or 
not is it is in an LPAR group, so this resource does not 
really become part of a larger pool of resources. Its ef- 
fect in an LPAR group though is that it can change what 
type of workload can effectively be run in one LPAR 
group member versus another 
[0051] In one example, a resource to be shared 
among a plurality of logical partitions is a CPU resource. 
The OS/390 workload manager redistributes CPU re- 
sources across logical partitions by dynamically adjust- 



50 



55 



6 



11 



EP 1 089 173A2 



12 



ing one or more relative processor weights associated 
with the logical partitions. WLM understands when an 
important workload is delayed because the weight of the 
partition it is running within is too low. WLM can help this 
workload by raising the weight of this partition and low- 
ering the weight of another partition, thereby providing 
additional CPU capacity to the important workload. CPU 
resources dynamically move to the partitions where they 
are needed, as workload requirements change. 
[0052] In one embodiment, the scope of WLM man- 
agement of logical partition weights is a logical partition 
group. As one example, WLM adjusts logical partition 
weights, but maintains the sum of the weights of the par- 
titions in the group constant. Maintaining the sum con- 
stant, keeps the overall CPU resource allocated to the 
group the same relative to other independent groups on 
the same physical computer. Therefore, when WLM 
raises the weight of one partition, it lowers the weight of 
another partition in the same group. 
[0053] The management of logical partition weights is 
an enhancement to WLM's goal oriented resource allo- 
cation techniques, which are described in, for instance, 
U.S. 5,473,773, issued December 5, 1995; and U.S. 
5,675,739, issued October 7, 1997. 
[0054] As described in those patents, WLM controls 
the allocation of CPU resources within a logical partition 
by adjusting CPU dispatching priorities. CPU dispatch- 
ing priorities are assigned to work at a service class lev- 
el. However, there are various situations in which the 
adjustment of dispatching priorities does not help the 
service class. For example: 

1 ) The service class is already alone at the highest 
CPU dispatching priority allowed to non-system 
work. 

2) Changing CPU dispatching priorities to help the 
service class will have too large a negative impact 
on other service classes that are of equal or higher 
importance. 

[0055] Thus, when WLM finds that a service class is 
missing its goals due to CPU delay, which cannot be 
helped by adjusting CPU priorities, WLM considers ad- 
justing the weight of the partition associated with the fail- 
ing service class. 

[0056] The service class to which WLM is considering 
allocating additional resources is called the receiver 
service class. When WLM has found a receiver service 
class missing goals due to CPU delay on a given parti- 
tion that cannot be helped for one of the reasons listed 
above, WLM considers raising that partition's weight. 
One embodiment of the logic followed by WLM to deter- 
mine if a partition's weight can be increased to help the 
receiver service class is described as follows, with ref- 
erence to FIG. 6: 

1 . Project the effect on the receiver class of increas- 



ing the weight of the partition, STEP 600. Increasing 
the partition's weight increases the CPU capacity of 
the partition. Since the CPU demand of the work in 
the receiver class is assumed to be constant, in- 

5 creasing the CPU capacity of the partition decreas- 
es the percentage of this capacity that the receiver 
service class demands. The projection of the ben- 
efit to the receiver service class is based on this de- 
crease in the percentage of available CPU capacity 

10 both the receiver service class and the other work 
on the system demand. 

2. Find another partition in the logical partition group 
to be a candidate to have its weight lowered, STEP 

15 602. This partition is known as the candidate donor 
partition. The candidate donor partition is chosen 
by, for instance, looking for the partition where the 
least important work is likely to be impacted by low- 
ering the partition's weight. 

20 

3. Project the effect on all service classes with work 
running on the candidate donor partition of lowering 
its weight, STEP 604. Decreasing the candidate do- 
nor partition's weight decreases the CPU capacity 

25 of the candidate donor partition. This decrease in 
CPU capacity means that the CPU demand of the 
service classes with work running on the candidate 
donor as a percentage of the capacity of the candi- 
date donor will increase. The projection of the neg- 

30 ative effect of reducing the candidate donor's weight 
is based on this increase in the percentage of avail- 
able CPU capacity that these service classes de- 
mand. 

35 4. Determine if this change in weight has net value, 
INQUIRY 606. That is, the benefit to the receiver 
service class overrides the negative impact to work 
on the candidate donor partition based on the goals 
and importance of the service classes involved. 

40 

5. If adjusting the weights does have net value, im- 
plement the proposed change to the partition's 
weights, STEP 608. If there is no net value, then a 
determination is made as to whether there are more 
45 candidate donor partitions, INQUIRY 610. If so, an- 
other candidate donor partition is chosen, STEP 
61 2, and processing continues at step 3, STEP 604. 
If there are no more candidate donor partitions, then 
processing ends, STEP 614. 

50 

[0057] To enable WLM running on one partition to 
make a projection on the effect of changing partition 
weights on work running on another partition, each par- 
tition has access to a shared data structure containing 
55 performance data about each logical partition in the 
group. This partition level performance data includes, 
for instance: 
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CPU requirements of work running on the partition 
by service class; 

How well each service class is doing towards its 
goal on the partition; 5 

CPU usage by CPU dispatching priority for the par- 
tition. 

[0058] In a preferred embodiment of the present in- 10 
vention implented in an OS/390 system, this shared da- 
ta structure is built and maintained in a coupling facility. 
However, other data sharing approaches could be used 
to implement this data structure, such as messaging or 
shared disk. 1 $ 
[0059] Described above is a capability for dynamically 
redistributing CPU resources of a computing environ- 
ment. The resources are redistributed across logical 
partitions, as one example, by dynamically adjusting 
logical partition weights. 20 
[0060] In addition to dynamically adjusting CPU re- 
sources of a computing environment, logical processor 
resources may also be dynamically adjusted. 
[0061] A logical partition is configured with one or 
more logical processors, which are dispatched on the 25 
central processor complexes' physical central process- 
ing units to execute work. To allow a partition to con- 
sume its assigned CPU capacity, sufficient logical proc- 
essors are to be configured to the logical partition. For 
example, consider the case of Logical Partition A run- 30 
ning on a CPC with ten CPUs. If a workload manager 
assigns Logical Partition A 50% of the CPC's capacity, 
Logical Partition A needs at least five logical processors 
to be configured to it. (Five logical processors could run 
on five of the CPUs or 50% of the CPC's capacity.) 35 
Should Logical Partition A later be assigned 95% of the 
CPC's capacity, Logical Partition A would then be con- 
figured with ten logical processors. Since WLM can dy- 
namically adjust the capacity assigned to Logical Parti- 
tion A with a statically defined logical processor config- 40 
uration, ten logical processors are configured to Logical 
Partition A in order to accommodate all possible capac- 
ity assignments. However, should Logical Partition A be 
assigned, for example, only 20% of the CPC's capacity, 
two problems arise from the statically defined logical 
processors: 1) Each of the ten logical processors will, 
on average, be allowed to consume physical CPU re- 
sources at the rate of only 0.2 of a physical CPU's ca- 
pacity (20% of ten CPUs divided by ten logical proces- 
sors equals 0.2 CPUs per logical processor). This can 50 
severely restrict workloads whose throughput is gated 
by a single task, since that single task will only be able 
to execute at 0.2 the capacity of the physical CPU - this 
is often referred to as the short engine effect; 2) Soft- 
ware and hardware efficiency is significantly reduced 55 
when having to manage ten logical processors, when 
only two logical processors are required. 
[0062] In order to address the above deficiencies, the 



configuration of a logical partition is not statically de- 
fined, but instead is dynamically adjusted. In one exam- 
ple, it is WLM that manages the partition and makes the 
dynamic adjustment. WLM can do this for each logical 
partition of a computing environment (or within an LPAR 
group). One embodiment of the logic associated with dy- 
namic adjustment of the configuration of logical proces- 
sors is described with reference to FIG. 7. 
[0063] Initially, a logical partition is configured with the 
minimum number of logical processors required to allow 
it to consume the capacity assigned to the logical parti- 
tion by workload manager (or the capacity actually being 
used, if larger), STEP 700. As the logical partition's ca- 
pacity assignment (or capacity use) changes, INQUIRY 
702, an evaluation is made to determine whether the 
number of logical processors configured to the logical 
partition should be altered, STEP 704. In one example, 
the number of logical processors configured to a logical 
partition remains close to the number of physical CPUs 
necessary to provide the CPC capacity assigned to (or 
used by) a logical partition. Thus, each logical processor 
executes at close to the capacity of a physical CPU and 
the number of logical processors to manage are mini- 
mized. 

[0064] In order to make the evaluation of whether to 
change the logical configuration, the following equation 
is used in one example: L=floor[max(W,U)xP+1.5] sub- 
ject to a maximum of L=P, where L=number of logical 
processors configured to a logical partition; W=percent- 
age of CPC capacity assigned to the logical partition; 
U=percentage of CPC capacity currently being used by 
the logical partition; and P=number of physical CPUs on 
a CPC, STEP 705. 

[0065] L is evaluated by workload manager based on 
the then current values of P,W and U at, for instance, 
regular and frequent intervals (e.g., every 10 seconds). 
Thresholds are used to determine if the actual value of 
L (L-act) for the logical partition should be raised or low- 
ered. If the newly calculated value of L (L-calc)is higher 
than the current value of L-act, INQUIRY 706, then L- 
act is raised to L-calc, STEP 708. Otherwise, if L-calc is 
a value of two or more lower than L-act, INQUIRY 710, 
then L-act is set to L-calc minus one, STEP 712. If L- 
calc is equal to L-act or only a value of one below L-act, 
no change in the value of L-act for the logical partition 
is made, STEP 714. Through the use of these thresh- 
olds, unnecessary changes of L-act due to small work- 
load fluctuations are avoided, while still being respon- 
sive to quickly increasing capacity demands of work- 
loads. 

[0066] For further illustration, consider the following 
example: Assume P=10, W=U=24%. A static configura- 
tion of logical processors would require L(static)=10 to 
handle the case should W grow to greater than 90%. 
However, in a preferred embodiment of the present in- 
vention: L(Dynamic)=floor[max(.24,.24)x10+1.5]=3. 
Thus, in this example, L(static) would constrain a single 
task to execute at 0.24 of a physical CPU, while L(Dy- 
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namic) allows a single task to execute at 0.80 of a phys- 
ical CPU, thereby providing a 233% increase in through- 
put for workloads gated by single task performance. Ad- 
ditionally, the software and hardware efficiency is signif- 
icantly improved since, in this example, only three logi- 
cal processors are managed rather than the ten logical 
processors needed for L(static). 
[0067] Described above are various mechanisms for 
managing resources of a computing environment. Phys- 
ical shareable resources are managed across logical 
partitions of a computing environment. The logical par- 
titions are grouped to enable resource sharing through, 
for instance, priority based resource allocations. This re- 
source sharing includes, for example, dynamic manage- 
ment of CPU resources across LPARs; dynamic CHPID 
management across LPARs; I/O priority queueing in the 
channel subsystem; and dynamic management of mem- 
ory across LPARs. 

[0068] In the embodiments described above, various 
computing environments and systems are described. It 
will be appreciated that these are only examples and 
are not intended to limit the scope of the present inven- 
tion. Likewise, the flow diagrams depicted herein are 
just exemplary. There may be many variations to these 
diagrams or the steps (or operations). For instance, the 
steps may where appropriate be performed in a differing 
order, or steps may be added, deleted or modified. 



Claims 

1. A method of managing logical processors of a com- 
puting environment including one or more logical 
partitions, said method comprising the steps of: 

configuring a logical partition of said computing 
environment with one or more logical proces- 
sors; and 

dynamically adjusting the configuration. 

2. The method of claim 1, wherein said dynamically 
adjusting is in response to the workload of said log- 
ical partition. 



with one or more thresholds to determine whether 
the adjustment is to be made. 

6. The method of claim 5, wherein said predefined 
5 equation comprises: 

L=floor[max(W,UrP+1.5], 

10 wherein: L=number of logical processors config- 
ured to said logical partition; W=percentage of cen- 
tral processor capacity assigned to said logical par- 
tition; U=percentage of central processor capacity 
currently being utilized by said logical partition; and 

is P=number of physical processors that can be allo- 
cated on the central processor associated with said 
logical partition. 

7. The method of claim 6, wherein said equation is 
20 subject to a maximum of L=P. 

8. A computer program for implementing the method 
of any preceding claim. 

25 9. A system for managing logical processors in a com- 
puting environment including one or more logical 
partitions, said system comprising: 

means for configuring a logical partition of said 
30 computing environment with one or more logi- 

cal processors; and 

means for dynamically adjusting the configura- 
tion. 

35 



40 



3. The method of claim 1 or 2, wherein said dynami- *5 
cally adjusting comprises the step of increasing the 
number of logical processors allocated to said log- 
ical partition. 



4. The method of any preceding claim, further com- 50 
prising the step of making a determination that said 
configuration is to be adjusted at a plurality of time 
intervals. 



The method of claim 4, wherein said step of making 55 
a determination comprises the step of using a pre- 
defined equation in making the determination, the 
result of said predefined equation being compared 
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